\chapter{Design}\label{cha:design}
In this chapter, we present the design of our peer-to-peer approach for
Wi-Fi sharing with HIP as building block. The chapter consists of five
sections. 
In section \ref{sec:design_authentication} we discuss the design of  user 
authentication and how we integrate  it in the HIP Base Exchange. In section \ref{sec:tunneling}
we present the implementation of the traffic tunneling. In section
\ref{sec:design_mobility} we talk about the
possibility to make mobility work.  Section
\ref{sec:design_opt} and \ref{sec:design_business} show how the
model can be optimized and how different business models can be supported. 
Since the
traffic is protected by IPsec automatically, we do not need to discuss
confidentiality.
\section{Authentication}\label{sec:design_authentication}
\subsection{Authentication Roles}\label{sec:authentication}
There are three roles in the authentication process of our  
Wi-Fi sharing model:
\begin{itemize}
\item \emph{Mobile User}: User with a mobile device (Laptop, PDA
etc.) who wants to use an external access point for the Internet access.
\item \emph{Access Router}: router through which a member of a community can
access the Internet.
\item \emph{Home Router}: the router of the mobile user, which is typically
located at the mobile user's home.
\end{itemize}
For our  Wi-Fi sharing model, the following facts must be
guaranteed through the authentication process:
\begin{itemize}
\item The home router is a valid member of the Wi-Fi sharing community.
This means the home router is also providing bandwidth for others and 
forwards the traffic to their own home routers. Otherwise a selfish mobile
user will only use other's access points but  not share his bandwidth to
others.
\item The mobile user is the owner of the home router or he is
authorized to use the home router. The home routers here can also be servers
of a Wi-Fi reseller or Internet Service Providers.
\item The access router must be sure that the identity of  both the mobile user and the home
router is authentic.
\end{itemize}
We summarize the terms again here: a \emph{mobile user} is someone
who wants to get Internet access through an external wireless router and is
synonym for terms like \emph{mobile client} or \emph{nomadic user}.
The access router 
referred here is actually 
an ``all in one''-device which integrates the
functionality of router, switch, wireless access point and firewall. So in
our thesis, the term \emph{access router} is referring to such a box and is synonym
for the \emph{middlebox}, because it is located in the middle of the
communication path.  The \emph{home router} is a router or
a computer located at a mobile user's home or operated by a reseller or a
service provider and is synonym for \emph{provider}.

\subsection{Integration of the Authentication in the Base Exchange}
Based  on the consideration in the previous subsection, it is no
problem to design a new and separate protocol for authentication. But since
a Base Exchange always takes place before a HIP association is established, and 
the host
peers authenticate mutually in the Base Exchange, a separate authentication
protocol will be redundant. It is much more elegant and convenient to 
integrate the authentication in the Base Exchange.

However, the Base Exchange needs to be extended and modified to fulfill
the task of authentication mentioned above.
Especially the middlebox must take part in the authentication process. 
\subsubsection{Certificate based Authentication}\label{sec:design_pcert}
Although the HIT is self-certificating, it only proves that the HIT is a
legitimate identifier in association with a private key. On the other hand,
the HIT and it's private key do not provide information whether a home
router is a valid member of the community. For this purpose, we need a
\emph{Certificate Authority} (CA), which all parties in the community 
trust, to issue certificates.

With the signature of the CA, a certificate binds a public key with an
identity. Anyone who has the public key of the CA can verify the validity
of the certificate and thus ensure that the owner of the certificate is a
valid member of the community.

There is already a definition of HIP parameter certificate \texttt{CERT} 
with
type 768
and variable length in the Internet-Draft of the Host Identity Protocol \cite{hip_draft}.
Because the size of standard certificates
\footnote{A Standard X.509 certificate with a key length of 1024 bits is 
about 5 KB}, including a certificate in a HIP packet will cause the packet
to be fragmented. 
According to \cite{kau03}, fragmentation can be used for DoS-attacks.
Therefore, the HIP protocol recommends that the certificate, if used in
the Base Exchange,  should be
defined as ``Hash and URL'', i.e. an address together with its hash value.

However, this recommendation has its
own problems. Firstly, the certificates must be stored in a reliable place
so that they can be retrieved if needed, this requires the deployment of a
central server and  will break our decentralized approach of the
authentication. Secondly, if the network connection is not optimized and
stable, the retrieve of the certificate will become the bottleneck of the
whole authentication process.

We propose the use of a \emph{community certificate}, which provides the same 
semantic as a normal certificate, but its size will be small enough to be 
included in a HIP
packet. Because the HIT is self-certificating, there is no need to include
the public key in the community certificate. The certificate is issued to the
HIT as subject, together with the validity time and other necessary information,
which will be signed by using the CA's private key.

We only designed certificates with DSA signature 
based on the following considerations:
\begin{itemize}
\item As discussed in section \ref{sec:key_length}, the signature size of
RSA algorithms is the same as the key length, whereas the signature of DSA
algorithm has a much shorter size. 
\item As described in the HIP protocol \cite{hip_draft}, a  HIP packet 
cannot be made of more 
than one IP datagrams.
\item The HIP protocol \cite{hip_draft} defines that for the HIP packets, 
it is required in IPv4 that fragmentation must be implemented, whereas in 
IPv6,
the implementation of fragmentation is only recommended. 
The reason is that in IPv6, the
minimum MTU is 1280 bytes which is big enough for normal HIP packets.
But 1280 bytes may not be enough for our extension for
Wi-Fi sharing. For example, in the I2
packet, if the RSA key size is 2048 bits, then only the
signatures and the Host ID will take (3*2048)/8= 768 bytes.
\end{itemize}

\subsubsection{Token and Trust Chain}\label{sec:chain}
The authorization of the mobile user to use the home router as tunnel
endpoint and for Internet access can be done in a simple way by inquiring
the database of the home router. This is sufficient
for normal private users. But for service providers who manage a huge
number of customers, a dedicated server must be used for inquiring the
authorization. We propose the use of token which provides a flexible way of
authorization.

Tokens are designed to act as tickets to access the Internet through a HIP
tunnel on the other endpoint. Only a mobile user with a valid token will
be allowed to establish the tunnel and through which to the Internet. 

A token should be something which the provider (home router) gives exclusively to the
mobile user. A basic 
token consists of the HIT to which the token is issued, the valid time
and other information which are signed by using the 
home router's private key.  
In this context, a token can be considered as a 
certificate variety with the home router as CA. 

Again, there is no need that the public key (Host Identity) should be included
in the token, because it will be exchanged in the Base Exchange. We have only
designed token with DSA signature, for same reason as stated above. 

Since the CA is trusted by the middlebox, it trusts the home router by
verifying the community certificate. The home router trusts the mobile client by
inquiring the trust database or verifying the token. Thus the middlebox will
also trust the mobile client. This characteristic is especially helpful for
the optimization of our model, as described in section
\ref{sec:design_opt} in detail.
\subsection{Authentication Steps}
In the following subsections, we introduce the design of our modified and 
extended
Base Exchange, in which the authentication is integrated. We firstly
mention the original content of the HIP packets and then explain what and
why we
modified and added in the packet. Then we explain how the middlebox handles
each packet. Figure \ref{img:bex_overview} illustrates the overview of the
process.

\begin{figure}[htb]
 \centering
 \includegraphics[width=14cm]{pics/bex_overviwe}
 \caption{Overview of the authentication process}
 \label{img:bex_overview}
\end{figure}
At the registration phase, the community CA issues certificate to the home
router and the home router issues token to the mobile user. This process
needs be to done only once.

\subsubsection{The I1 Packet}
The I1 packet which is sent by the Initiator, initiates the Base Exchange.  
In our Wi-Fi model, the Initiator needs to set an additional Wi-Fi flag to
indicate
that a HIP association will be established for the Wi-Fi sharing purpose.

Besides the Wi-Fi flag, nothing more is added or modified to the original
packet. This is designed to keep the I1 packet to be minimal so
that the Base Exchange can not be used as covert channel to carry
unauthorized information.

Since the I1 packet is not protected,
it could be used by an attacker to
start an I1-flood aimed at exhausting the CPU power of the middlebox and/or
responder, thus to keep the I1 packet to be minimal can also prevent
DoS-attacker, because the middlebox and/or the Responder do not need to
spend much CPU time and memory to handle the I1 packet. 

On seeing the Wi-Fi flag,
the middlebox will let the packet pass through without any action. Figure
\ref{img:i1} illustrates the process.
\begin{figure}[htb]
 \centering
 \includegraphics[width=14cm]{pics/i1}
 \caption{Processing the I1 packet}
 \label{img:i1}
\end{figure}
\subsubsection{The R1 Packet}
The processing of the I1 packet and the creation of the R1 packet are the 
same as described in section
\ref{sec:bex}. 

On intercepting the R1 packet, the middlebox will process the packet as
follows:

A nonce is added into the R1 packet which should be signed by the
Initiator. The nonce used here has two functions. Firstly it prevents that
the R1 packet will be reused in replay attacks. Secondly, since the nonce
must be signed by the Initiator, the middlebox can validate that the
Initiator's HIT is authentic by verifying the signature. In this way,
identity impersonation will not be possible.

Since the signature of the next packet (I2) will be verified by the middlebox, an
attacker could misuse this fact to exhaust the CPU power of  the 
middlebox, because the middleboxes are normally weak in CPU power and the
verifying a PK signature is expensive in terms of CPU cycle. To prevent
this kind of attack, a second puzzle is added by the middlebox which must
be solved by the Initiator.
Just like the puzzle which is set by the Responder in the original R1 packet,
the middlebox can also adjust the difficulty of the puzzle, based on 
different factors like level of trust, current load etc. Figure \ref{img:r1}
illustrates the process.
\begin{figure}[htb]
 \centering
 \includegraphics[width=14cm]{pics/r1}
 \caption{Processing the R1 packet}
 \label{img:r1}
\end{figure}

\subsubsection{The I2 Packet}
In the I2 packet, the
solution to the puzzle from the Responder and the second puzzle from the access 
router must be included.
Without correct solutions, the I2 message is discarded already by the
access router.  
Besides the contents of a normal I2 packet, 
the Initiator can put an optional 
token into the packet. 
As introduced earlier, a  token is something which the home router issued
exclusively to the mobile user and proves either the ownership of the home
router or implies that the mobile user is permitted to use the home router
for the Internet.

On intercepting the I2 packet, the middlebox must firstly check the
solution of
the puzzle it added. If the solution is wrong, the I2 message will be 
discarded. Only after that, the middlebox  
verifies the signature of the I2 packet where the nonce is
included. 

The optional token will also be checked. In this case, the presence of the
token should suffice, because the validity should be verified by the peer
and another verification of the signature is a heavy burden for the router.

We also add a puzzle for the Responder. This is designed to prevent
DoS-attacks aimed at paralysing the middlebox. As described in the next
subsection, the middlebox must do 2 PK operations to process the R2 packet.
This can be used by an attacker who controls remote Responders to put bogus
certificate and signature in the R2 packet. Since the signature
verification is expensive for the middlebox in terms of CPU cycle, it must
be protected against such attacks.

To prove the identity of the Responder and to prevent replay attack, another nonce is added into
the I2 Packet, which should be signed by the Responder. Figure \ref{img:i2}
illustrates the process.
\begin{figure}[htp]
 \centering
 \includegraphics[width=14cm]{pics/i2}
 \caption{Processing the I2 packet}
 \label{img:i2}
\end{figure}
\subsubsection{The R2 packet}
The R2 packet is the last packet in the base exchange and the packet is processed by the routines
as describe in section \ref{sec:bex}. 
The solution of the puzzle is added in the packet.
The nonce from the middlebox
is also put into the  area where the signature can cover. 

To make sure that the home router is a valid member of the community, the
router must prove that it possesses a certificate which is issued by the
Certificate Authority (CA)
of the community. So a certificate is included in the R2 packet.

In the first version of our design, the certificate is included in the R1
packet. This can be used by an attacker to paralyse the middlebox: he can
use remote computers under his control to start lots of Base Exchange
through the access point. Although the remote computers' certificates are
not valid, they must be verified by the access. A normal wireless router
must take about 100 ms to verify a certificate, as measured in Chapter
\ref{cha:evaluation}.

Thus, the certificate is included in the R2 packet. At this time, the
Initiator has spent considerable time to solve the puzzle and the signature
of the nonce has already been verified.
The R2 packet will then be sent  back to the Initiator.

The middlebox intercepts the R2 packet, and verifies firstly the solution
of the puzzle. If it is correct, it retrieves the certificate
and verifies it. 
We assume that the access router is already in possession of the
CA's public key. The middlebox  will only forward R2 to the Initiator if 
the certificate is
valid, 
otherwise the packet will be discarded. 
After that, the middlebox proves the signature of the
nonce by the Responder and if it is valid, and the R2 packet will be
forwarded to the Initiator. Figure \ref{img:r2} illustrates the process.

\begin{figure}[htp]
 \centering
 \includegraphics[width=14cm]{pics/r2}
 \caption{Processing the R2 packet}
 \label{img:r2}
\end{figure}
\subsubsection{Proof of the Authentication}
After a successful Base Exchange, the middlebox possesses the following
information:
\begin{itemize}
\item The home router is a valid member of the community based on the
verification of the certificate.
\item The home router and the mobile client are not impersonating their
identities based on the signatures of the nonces.
\item The mobile user is the owner of the home router or he is allowed to
use the router for the Internet. 
\end{itemize}
Based on the chain of trust as mentioned in subsection \ref{sec:chain}, the
middlebox trusts the both communication peers and will unblock the following
ESP traffics.

\subsection{New HIP Parameters for Authentication}
As described in the design of authentication process, we need to define
new HIP parameters for the extension and modification of the Base Exchange. 
The Internet draft of Host Identity Protocol \cite{hip_draft} gives  guideline for defining new parameters.
Table
\ref{tb:number} summarizes the definition of 
the new parameters which we introduced above.
\begin{table}[htbp]
\begin{tabular}{|l|l|l|l|}
\hline
TLV & Type & Length & Data \\ \hline
nonce\_s & 836 & variable & Nonce echoed back under signature \\
c\_cert & 63426 & variable & Community certificate\\
token & 63428 & variable & Token for the mobile user\\
puzzle\_r & 63434 & 12 & K and Random \#I, set by the middlebox\\
solution\_r &63436 & 20 & K, Random \#I and puzzle solution J\\ 
nonce\_r & 63438 & variable & Nonce added by the middlebox\\
\hline
\end{tabular}
\caption{New parameters defined for authentication}
\label{tb:number}
\end{table}

The definition of the new parameters is based on the following
considerations:
\begin{itemize}
\item The new parameters have all even numbers as type number. This kind of
parameters are called \emph{non-critical} parameter. The HIP protocol recommends
to define new parameters as non-critical parameters.
\item The \texttt{nonce\_s} has a type number between 0-1024 and thus will be
covered by the signature. Every other parameter has the type number between
62464-63487, because they do not need, or are not possible to be protected
by the signature.
\end{itemize}
\subsection{Control of the ESP Traffic}
ESP traffic is generally blocked by the middlebox before any association
between SPI (Security Policy Index)  and destination IP address has been
established. 

Such associations can only be collected  during the Base Exchange 
and the Update process. The access router takes part in the authentication
and Update process and will possess such associations. An ESP packet will
only be forwarded if its SPI and its destination IP address match the item
in the traffic control database of the middlebox.

Since the UDP-encapsulated ESP traffic uses the same UDP port number as the
UDP-encapsulated HIP control packets, the traffic control must retrieve the
SPI in the payload of the UDP packet. The traffic control program must
update the mapping between SPI and IP address if the peer at the other
endpoint changes his IP address and starts a Update process.
\section{Tunneling}\label{sec:tunneling}
Tunneling is a technology which encapsulates the packets of an existing 
protocol as payload into  packets of a new protocol. There are many reasons 
for using tunneling, some of them are aimed to create a logical path 
between two endpoints of different networks, others are aimed to 
secure the transmission by encrypting the payload, or because it is a convenient way to traversal NATs or firewalls.

Because of the tunneling overhead, the payload packets to be transmitted
over the tunnel must be fragmented to meet the MTU (Maximum Transmission
Unit) requirements of a network device. On the other side, the data must be
defragmented so that the datagrams can be processed by a corresponding
program.

\subsection{The Linux TUN/TAP Device}\label{sec:tun}
The TUN/TAP devices are virtual network devices in the Linux kernel which
are designed primarily for tunneling.
The TUN device is designed for IP
tunneling, i.e. it reads and writes IP packets. On the other hand, the TAP
device is designed for Ethernet tunneling, i.e. it reads and writes
Ethernet frames.

The TUN/TAP devices combine the advantages of network devices and character
devices. Instead of receiving packets from  physical
networks, a TUN/TAP device receives packets from userspace
programs. It sends the packets not to physical networks, but to  user
space programs. The userspace program can firstly process the packets
like compressing, encrypting or modifying the payload of the packets,
and then sends them over TCP or UDP.
\subsection{Tunneling for Wi-Fi Sharing}
Forwarding the Internet traffic from the 
mobile client
to the home router and then to the Internet by using the TUN device offers several
advantages. 
Firstly, the tunneling packets can be better controlled. The administrator
can apply iptables rules based on the TUN device rather than on packets. 
Secondly,
using the TUN/TAP device also facilitate the programming work, because in
UNIX the device is considered as a file. The programmer only needs to use read and write
functions to get and put packets from and to the TUN-device.

The tunneling programs for Wi-Fi sharing, which are divided into a server and a client part,
are normal IPv6 programs, but they are using HIT of the peer as
destination address and their own HIT as source address. After a HIP
association is established between the Home Router and the Mobile Client, a
TUN-device is created and configured at each endpoint. With route settings
we specify that the TUN device is the default device, i.e. all traffic to
the Internet is sent by the TUN device and traffic from the Internet will
be sent to the TUN device. 

The tunneling program packs the IP-packet from
the TUN device as payload into a new IP packet and sends it to 
the peer with 
his HIT as destination address. The new IP packet
will be firstly handled by the IPsec BEET mode kernel module, as defined in SPD. During
the BEX, a mapping between the HIT and the outgoing IP address has been
made, so the IPsec BEET mode module can perform an
inter-family transformation where an IPv6 header is replaced by an IPv4 header.
The IPv4 packet is transmitted to the peer over normal IPv4 network.  On 
receiving the packet, the peer  enquires the SAD based on the SPI and the
IP address, and lets the IPsec BEET mode module perform an inter-family transformation from
IPv4 to IPv6, and then passes the packet to the tunneling program.
The server part of the
tunneling program unpacks the IPv6 packet and sees that the payload is a normal
IPv4 packet. Since the TUN device of the server is set to the default
gateway of route setting, the unpacked packet with the destination address
outside of the subnet will be sent to its destination over the normal
TCP/IP stack of the peer
host. Figure \ref{img:tunneling} explains how the tunneling works.

After the tunnel is established, the route setting must be adjusted so that
the home router will act as the default gateway of the mobile user. The
default gateway so far, which is normally the access router, must be deleted,
and the virtual IP address of the home router will be set as the default
gateway.
\begin{figure}
 \centering
 \includegraphics[width=15cm]{pics/tunneling}
 \caption{Tunneling for Wi-Fi Sharing
 }
 \label{img:tunneling}
\end{figure}
\section{Mobility}\label{sec:design_mobility}
As described in section \ref{sec:requirement_mobility}, mobility is a highly
desired feature for Wi-Fi deployment. Since the two endpoints of the tunnel
are HIP-capable, it is possible to realise mobility in our model.

A mobile user
moves from one access point to another. The IP address he gets assigned
from the access points are both private IP addresses, i.e, the mobile user
moves from \emph{behind NAT} to \emph{behind NAT}. Since the Internet
packets are transferred as payload over the tunnel, the connection remains
as long as the tunnel exists. Since we assume that a mobile user only have
one wireless network interface with only one assigned IP address, we don't
discuss multihoming  in our Wi-Fi sharing model.

The mobility for normal HIP association is introduced in section
\ref{sec:mobility_def}. In our design, the difference is that the middlebox
must participate in the Update process, hence we need to modify the mobility
extension to meet our requirements.

The two endpoints have
already established a HIP association which is protected by ESP. So there
is no need to start a Diffie-Hellmann key exchange. 
During the Update process, the mapping between HITs and IP addresses and the 
SADs should be updated. For a middlebox, it should
fulfill the same authentication task as it does in the Base Exchange, which
is described in section \ref{sec:design_authentication}.

In the Base Exchange, the Host IDs of the Initiator and Responder are 
exchanged, thus in the original Update protocol, no Host ID is included in
the HIP Update packet. Since the middlebox must verify the signature of
the nonces during the Update process, the protocol
must be extended so that the Host IDs are included in Update packets. The
certificate of the home router should also be included in the Update
message so that the middlebox can verify it. The
middlebox also adds a nonce for each peer which should be signed by the two
endpoints to prevent replay attack and identity impersonation.

Based on the descriptions above, we explain our modification of the Update
process. Figure \ref{img:update_overview} illustrates the overview of the Update process.
\begin{figure}[!htb]
 \centering
 \includegraphics[width=14cm]{pics/update_overview}
 \caption{Overview of the Update process}
 \label{img:update_overview}
\end{figure}

\subsubsection{The first Update packet}

The mobile user moves from one access point (AP1) to another (AP2). In the 
meantime, his connection gets lost from the AP1 for a short time and then
he gets connected with AP2. Upon getting new IP address, the mobile user
sends a Update message (the first Update packet, or U1 as depicted in Figure \ref{img:u1}) to the peer. The content of the message is the same
as described in section \ref{sec:mobility_def}. The only difference  
is the Wi-Fi
flag, just like the Wi-Fi flag set in the I1 message to indicate that an
Update process for Wi-Fi sharing will take place.

The first Update packet is intercepted by the middlebox. By checking
the packet type and the control bit, the middlebox will know that the
mobile user wants to update a HIP association through the access
point and lets the packet pass through. Because the Update process is a
three way handshake process, a nonce must be added to the
packet which the Responder must sign and echo  back.  The middlebox knows now SPI
from the \emph{esp-info} parameter in the packet and the corresponding 
destination IP. The process is depicted in Figure \ref{img:u1}
\begin{figure}[htp]
 \centering
 \includegraphics[width=14cm]{pics/u1}
 \caption{Processing the first Update packet}
 \label{img:u1}
\end{figure}

\subsubsection{The second Update packet}
Based on the information contained in the received first Update packet, the
peer host must update the mapping between the HIT and the new
destination IP address. Since the middlebox will block the traffic until
the Update process is completed, there is no need to do specific address
verification.

Since the second Update packet is the only packet sent by the Responder, 
everything necessary must be packed into it. In addition to the original content, 
the nonce added by the middlebox will be put in the singed area and be packed
together with the Host ID and the certificate into the packet. The Responder
sends this
Update packet to
the mobile host at its new address. 

From the \emph{esp-info} parameter contained in the second Update packet, 
the middlebox knows now the
mapping between SPI and destination IP to the mobile client.
The middlebox retrieves the Host ID and the certificate 
from the second Update message. 
The verification of the certificate and the signature is postponed to the
phase when the
next Update message is processed by the middlebox. This design is based on
the consideration that an attacker could paralyse the middlebox by starting
a bogus Update process aiming at consuming the CPU power of the middlebox.

Instead, the middlebox adds a puzzle in the second Update packet. The puzzle
has the same purpose as the puzzle in the Base Exchange. The puzzle must be
solved by the mobile client and the solution must be included in the next
Update packet. In this way, the middlebox can prevent or at least slow down
the DoS-attacks, because an attacker must spend considerable CPU time
before the middlebox will verify the certificate and the signature of the nonces.
The process is depicted in Figure \ref{img:u2}.

\begin{figure}[htp]
 \centering
 \includegraphics[width=14cm]{pics/u2}
 \caption{Processing the second Update packet}
 \label{img:u2}
\end{figure}

\subsubsection{The third Update packet} 
As described in section \ref{sec:mobility_def}, the third Update packet which
contains the \emph{echo-response} parameter completes the Update process.
The nonce which is added by the middlebox is 
put into the area where the signature can cover. Together with his Host ID
and the optional token, the packet is  sent to the peer.

On intercepting the third Update message, the middlebox firstly checks the
solution of the puzzle. Only if the solution is correct, the middlebox will 
retrieve the Host 
ID and then verify the signature of the nonce. It then
verifies the certificate of the home router and its signature of the nonce from the last Update packet. Figure
\ref{img:u3} depicts the process.
\begin{figure}[htp]
 \centering
 \includegraphics[width=14cm]{pics/u3}
 \caption{Processing the third Update packet}
 \label{img:u3}
\end{figure}

After the Update process is complete, the middlebox program will unblock
the ESP traffic so that both peers can continue their connection. 

\subsection{Middlebox State Machine and Error Handling}
We use state machines to summarize the behavior of the middlebox program
and to show how to handle errors.
Figure \ref{img:state_machine} illustrates the state machine for the
authentication in the Base Exchange (BEX state machine) and  
Figure \ref{img:sm_update} shows the behavior of the
middlebox program for the Update process (Update state machine). Both state
machines have 3 states and 7 possible transitions.
\begin{figure}[htp]
 \centering
 \includegraphics[width=14cm]{pics/state_machine}
 \caption{Authentication State Machine}
 \label{img:state_machine}
\end{figure}
\begin{figure}[htp]
 \centering
 \includegraphics[width=14cm]{pics/sm_update}
 \caption{Update State Machine}
 \label{img:sm_update}
\end{figure}
\subsubsection{State \emph{unauthenticated}}
Both state machines start in state \emph{unauthenticated}. In this state, 
the
middlebox program drops all ESP traffic. For HIP control packets, only I1
and the first Update packet U1 with Wi-Fi flag will be forwarded, packets
of other types will be dropped. 

For the BEX state machine, receiving the I1 packet with Wi-Fi flag will not
trigger the transition to a new state. This is designed to
prevent DoS-attacks, because the I1 packet is not authenticated as
described in section \ref{sec:bex}. 
The BEX state machine transits to the state \emph{authenticating} on
receiving the R1 packet.
On the other hand,
the Update state machine transits to the state
\emph{authenticating} on receiving the first Update packet.
\subsubsection{State \emph{authenticating}}
In the state \emph{authenticating}, the middlebox program participates in
the Base Exchange or Update process. \emph{Valid HIP packets} or
\emph{valid Update packets} refer to the packets which come in the right
order, and with the right parameters required by the middlebox like solutions
of the puzzle or certificate. Valid packets will be accepted and processed.
In this state, there is no relationship between SPI and IP before the
authentication or Update process is completed, thus, all ESP
traffic is invalid and must be dropped. 

The middlebox program runs a timer for authentication and for the Update
process. If a timeout is
reached between the HIP control packets or between the Update packets, 
the program will assume that the
association is not valid anymore and transits to the start state
\emph{unauthenticated}.  

The middlebox program transits to the state \emph{authenticated} if in the
BEX state machine the BEX is complete and the first ESP packet is received.
For the Update state machine, if the Update process is completed and the
first ESP packet is received, it transits to the state
\emph{authenticated}.
\subsubsection{State \emph{authenticated}}
In the state \emph{authenticated}, valid ESP traffic is forwarded.
\emph{Valid ESP traffic} means ESP packets with SPI and IP addresses which
matches the records in the traffic control database of the middlebox
program. \emph{Invalid ESP traffic} does not belong to the IPsec channel
and should be dropped. 

In this state, valid HIP control packets are also forwarded. \emph{Valid
HIP control packets} can be necessary HIP packets like NOTIFY or CLOSE
packets etc. 

The middlebox program runs a timer for ESP traffic. If a timeout is
reached between ESP packets, the middlebox program will assume that the
association is not valid anymore and transits to the start state
\emph{unauthenticated}. 
This scheme is valid both for the BEX state machine and for the Update
state machine.

\section{Optimization} \label{sec:design_opt}
Based on the descriptions above, the Internet access should be sufficient
for normal uses like WWW or E-Mail. However, for application which requires
a short latency like VoIP (voice over IP), this configuration may not be
good enough
because transmission over the tunnel will increase latency. 

Moreover, since the entities building our Wi-Fi sharing community are normal
home routers, there may be situation where the home router is down due to
software or hardware issues. 

Another problem is the fact that the most broadband subscriber get their
Internet access using technology like ADSL (Asymmetric Digital Subscriber
Line) with a much lower up link speed. Thus, the up link speed of the home
router will limit the bandwidth of the mobile client.

Our Wi-Fi Sharing model should support a mode where a tunnel to the
home router is not required.  In this
mode, the access router acts as a tunnel endpoint. 
The token can be used to map the real world identity and the home router.
We describe the protocol modification and extension for this case in the
following subsections.
\subsection{Wi-Fi Sharing as HIP Service}
The HIP Registration Extension \cite{hip_registration} defines an
architecture for a mobile host to register with a service. The term
service is not fixed and may refer to different kind of services like
rendezvous server \cite{hip_rendezvous} or a middlebox. In this way, we can
define the optimized Wi-Fi sharing as a service which is provided by an
access router. To use it, the mobile client must register the service with
the access router.

We propose an authentication process which is
integrated in the Base Exchange while using the HIP Registration Extension. 
The term \emph{Requester} refers to the mobile client, because it 
requests a service (here Wi-Fi sharing) from the access router.
\emph{Registrar} refers to the access point, because it provides direct
Wi-Fi sharing for nomadic users.

According to \cite{hip_registration}, the registrar announces its service ability 
in
a \emph{reg-info} parameter which is included in the R1 packet. The
requester selects one service it want to use in the I2 packet. In the R2
packet, after the registrar has authenticated the requester, it can grant
or refuse the service and put the result in the \emph{reg-response}
parameter.

In the following subsections, we present our proposal of the authentication
process using the HIP Registration Extension.
\subsection{Authentication of the Optimized Mode}
Similar to the standard mode, the access router (middlebox in the standard
mode) must be sure of the following facts:
\begin{itemize}
\item The mobile user is the owner of the home router.
\item The home router is a valid member of the community.
\item The mobile user agrees that its activities will logged in a hashed
form.
\end{itemize}
The overview of the process is depicted in Figure \ref{img:bex_opt}.
\begin{figure}[!htb]
 \centering
 \includegraphics[width=14cm]{pics/bex_opt}
 \caption{Authentication in the optimized mode using HIP Registration
 Extension}
 \label{img:bex_opt}
\end{figure}
\subsubsection{The I1 packet}
The I1 packet is the same as in the standard mode. In addition to a normal
I1 packet, only a Wi-Fi flag is set by the mobile user. The access router
uses the destination IP address of the I1 packet to decide whether the
mobile user wants to start a standard mode or optimized mode.

\subsubsection{The R1 packet}
On receiving the I1 packet, the access router recognises from the
destination IP
address of the I1 packet that the mobile user 
wants to establish a direct HIP tunnel with it. 

The access router puts a \emph{reg-info} parameter in the R1 packet. The
\emph{reg-info} can be empty, if the access router does not provide the
direct Internet access, otherwise it means that the mobile client can
register himself for the direct Wi-Fi access.

If the access router provides the direct Internet access, it 
includes the certificate in the R1 packet, so that the mobile user can
be sure that he is not talking with a fake access point.

The access router also adds a nonce which is different than 1 into the R1 packet. The nonce must be
set to 1 in the next packet and put in signed area which indicates that the
mobile user agrees that his activities will be logged.
\subsubsection{The I2 packet}
On receiving the I2 packet, the mobile user firstly check the \emph{reg-info}
parameter. If it is empty, then there is no need to continue the BEX,
because no direct Internet access is provided by the access router. He must
try to use the standard mode or other access points. If the parameter is
not empty and direct Internet is provided, he chooses the service and puts
it in
the \emph{reg-req} parameter. 
Additionally, the mobile user also puts the
token, the certificate and the Host ID of the home router into the I2
packet. Since the certificate is issued to the HIT of the home router, the
Host ID can be checked to be authentic or not. The validity of the token
can be checked with the Host ID. 
From the chain of trust which we discussed in \ref{sec:chain}, the access
router trusts the mobile user. 
The nonce is set to 1 and put
in the signed area to indicate explicitly that the mobile client agrees
with the logging.
\subsubsection{The R2 packet}
The certificate and token will be verified at this stage. The nonce which
is set to 1 and signed means that the logging is allowed. 
If the authentication is successful, the registrar puts a
\emph{reg-response} parameter in the R2 which indicates that the requested
service is granted.
Then the R2
packet is sent to the mobile user and the authentication process is
finished.

After the service is granted, the access router will forward the mobile
user's traffic direct to the Internet and his activities will be logged as
described in section \ref{sec:logging}.
\subsection{Mobility}
Since in the optimized mode, the access router acts as the tunnel 
endpoint,
and if the user moves to another access point and builds from there a new
tunnel for the Internet, the connection will break. The only way to keep
mobility to work is to continue to use the previous access point as
tunneling endpoint. The Update procedure will be the same as described in
section \ref{sec:design_mobility}. However, once using mobility in the
optimized mode, the performance will not be optimal regarding latency
etc. The optimized mode can only be used as supplement of the standard
model.
\subsection{Logging and Privacy}\label{sec:logging}
Unfortunately, the approach of direct tunneling with the access router
as tunnel endpoint has still
uncleared problems of legal liability. Although the transmission in the air
is protected by HIP, logically the mobile user is still using the access
router for the Internet and in the current infrastructure of the Internet, the
IP of the access router still represents the ID of the mobile user. 
This problem will discourage
people to participate in wireless community.

Apparently, only the logging of the activities of guest users will make the
issue of liability manageable. However, due to the laws of privacy in
different countries, normal persons may not be allowed to log the activities of
others without their agreement, which makes the whole thing
complicated.

To solve the problem in a manageable way, we propose a logging system of
``hashed activities'', i.e., only the hash value of the IP address which a
user visited is recorded together with the start and end time. For the
operator of the access point, the records of hashed value are meaningless,
but if something bad really happens, we still have the possibility to prove
that somebody (based on the HIT)  else has done that at what time.

Whenever a new IP address is visited, the hash value of the IP is put into
the table together with the start time. If the user visits a new IP
address, the end time of the old IP address is added into the table and a
record for the new IP address starts.

Since a home router has only limited disk place, we can define that log
files from a certain size (for example 1MB) should be sent per e-mail or
FTP to the owner of the router, or even to the central server of the
community.

To ensure that a malicious operator of an access router won't forge the
hashed log, we could design a protocol which allows the mobile user firstly
to sign the log file and then the log file will be saved by the access 
router.
\section{Business Model}\label{sec:design_business}
Our peer-to-peer approach for Wi-Fi sharing makes also business models
possible. A community must be organized, in our introduction for example a
CA is needed to issue and manage certificates, the software must be developed and
maintained, and it would be wonderful, if subsidized wireless routers
could be offered by sponsors like FON today does.

The role of access control to the Internet trough a HIP tunnel can be performed
by the token, which we mentioned in previous sections. 
The structure of the token can be very flexible so that
different kinds of business models are possible. We present in the
following two possibilities.
\subsection{The Community Mode}
This is our peer-to-peer reply to the shortcomings of the current Wi-Fi sharing models
like FON. In this model, a community member provides his bandwidth to other
users, but they are only allowed to establish a HIP tunneling to his home
router and from there to the Internet. Community organizer like the company
FON may also set up server as tunneling gateway and sell tickets to people
who are not members of the community. The tickets can be tokens as we
described above.

This model is simple and easy to organize. ISPs can sell their
preconfigured router to make the deployment easier. The peer-to-peer Wi-Fi
sharing could be a 
highlight of their service, because the subscribers will have Internet 
access not only at home, but also at many place where they can find other
subscribers' home router. The performance
will not be optimal, but it gives the broadband subscribers a convenient way to
get secure Internet access almost everywhere with features like mobility in a very
inexpensive way. 
\subsection{The mixed Mode}
With the above introduced infrastructure and procedures, we present a
mixed model of Wi-Fi sharing which mixes the community efforts and the
commercial deployments.

The commercial hotspots are normally expensive and located in public places
like airports, railway stations and hotels \cite{pisa}.
On the other
hand, they are technically more powerful and reliable
than normal home routers. 
In the community, as long as a wired broadband
Internet access is available, the Wi-Fi sharing is possible. Our idea for the
mixed mode is that community Wi-Fi sharing and commercial hotspots could
complement each other.

Basically, besides the private community members, commercial hotspots are
also members of the community, i.e. part of their bandwidth 
can be shared by other community members which are not customers of a Wi-Fi
operator. Customers of the commercial hotspots operators can on the other
hand use the bandwidth which is provided by other community members. 

Since commercial hotspots are located mostly in public places whereas
private community routers in residential quarters, these two
kinds of members can complement each other well. Through the
cooperation with Wi-Fi sharing communities, a commercial hotspots operator
can increase their hotspots coverage and private community member will
benefit from sharing the hotspots in public areas. 

\section{Summary}
In this chapter, we firstly discussed the authentication problem in our
Wi-Fi sharing model. Instead of designing a new protocol for
authentication, we decided to integrate the authentication in the Base
Exchange. 

The Base
Exchange and the Update process need to be modified and extended so that 
we can integrate the user authentication in
HIP Base Exchange. Security is provided by the underlying IPsec and due to the
peer-to-peer nature of our design, our model is scalable. Additional
features like mobility are also provided by HIP.

We discussed the shortcomings of our design and proposed an approach 
to optimize it. 
We define the direct tunneling as service which the access router provides
and integrate the HIP Registration Extension in the authentication which is
also integrated in the Base Exchange. The token is used to map the real
world entity with the home router. Because of the chain of trust, the
access router will also trust the mobile user.

Our approach can also be used in several business models. We presented two
possible scenarios of business model using our peer-to-peer architecture.

